Core language

The core language is described in terms of a hypothetical machine (called an evaluator) which executes T code directly. In practice, the existing T implementations have (at least) two evaluators, both of which perform evaluation as a two-stage process consisting of compilation (syntactic and semantic analysis) followed by interpretation.

Evaluation is a process whereby an object called an expression (the term form is used synonymously with expression) is mapped to another object, called its value. Evaluation occurs in the context of a particular variable environment; see below. The expression is said to yield its value.

The evaluation mapping is not a purely mathematical mapping, since in some cases the evaluation of an expression may depend not only on the variable environment but on the state of the running T system, or on the state of the world outside it; and evaluation may cause changes in the state of system or the world, which may, in turn, affect future evaluations. These state changes are called side-effects.

The rules by which an object is evaluated are as follows:

Self-evaluating literals: All numbers, strings, and characters are syntactically valid expressions which, when evaluated, yield themselves. For example,
\begin{codexenv} \begin{tabular}{lll} -2102 & $\Longrightarrow$\ & -2102 \\ {\... ... ''A string.'' & $\Longrightarrow$\ & ''A string.'' \end{tabular} \end{codexenv}

The notation ``expression $\Longrightarrow$ value'' means that expression, when evaluated, yields value. (Note also that we are making use of the external object syntax itself as a notational device: ``the object -2102'' could be said more precisely as ``an object externally represented by the characters ``-2102''.'' Just as a program should never be confused with an object which represents it, an object should never be confused with a sequence of characters which notates it.)

Symbols: As evaluable expressions, symbols are interpreted as variable references. A symbol evaluates to its value according to the current variable environment. For example, in an environment in which the variable DELTA has the value 15, evaluating the expression DELTA will yield 15.

Symbols have many uses other than as names for variables. It is important not to confuse the use of a symbol as a datum manipulated by a program with the occurrence of a symbol as a variable reference in a program. Symbols do not have values a priori; variables only have values by virtue of the context in which they occur.

Lists: Non-empty lists are classified either as calls or as special forms. If the first element of the list is a symbol, and the symbol is a reserved word, then the list is a special form; otherwise it is considered to be a call. T reserved words , for example, the symbols QUOTE, IF, and LAMBDA. (However, see section [*].)

Special forms: The syntax and semantics of a special form are idiosyncratic to the reserved word which introduces it; descriptions of the meaning of expressions introduced by the various reserved words are therefore distributed throughout the manual.

Calls: Calls are evaluated as follows: the elements of the list (including the first) are evaluated, in an undefined order. The first must evaluate to a procedure; this procedure is applied to the rest of the values, which are called arguments. (The verbs call and invoke mean the same as apply.)

The evaluation order of arguments in a combination is undefined. ORBIT produces code in which the evaluation order of arguments is undefined and not necessarily left to right.

Particularly insidious bugs have resulted from LET, see page [*], forms whose clauses contain order dependent side effects. LET* should be used to ensure sequential evaluation order.